fix: process a node's own DKG messages ahead of queued peer messages - #8130

… commit phase

898351d perf(llmq): keep verified DKG contributions cached for the session (Konstantin Akimov)
49d9ed5 bench: measure the DKG commit step at llmq_400_85 size (Konstantin Akimov)

Pull request description:

  ## Issue being fixed or feature implemented

  Building a premature commitment for `llmq_400_85` takes about 5 seconds of single-threaded work, almost all of it avoidable. `SendCommitment` and the verification of every received premature commitment call `CDKGSessionManager::GetVerifiedContributions`, which reads each member's verification vector back from LevelDB and decodes it: 400 members x 340 BLS public keys, about 34 µs per key (25 µs subgroup check, 8 µs point decompression). The contributions cache was filled only by reads and expired after 60 seconds, so it was always cold at commit time, although the DKG session still held the same vectors in memory.

  #8130 reports that this delay made members miss short commit phases on mainnet, and fixes it. This PR is a smaller alternative to the cache part of #8130.

  ## What was done?

  - `WriteVerifiedVvecContribution` now also puts the vector into `contributionsCache`, sharing the pointer the session already holds (no copy).
  - `WriteVerifiedSkContribution` updates the cached entry, so a share verified or justified later is visible to the next lookup.
  - `CleanupCache` drops an entry after 60 seconds only when nothing else references its vector, so entries live as long as their session and entries loaded from disk expire as before.
  - Benchmarks for the commit step at 400 members / threshold 340: `BLSDKG_BuildCommitment_cold_400`, `BLSDKG_BuildCommitment_cached_400`, `BLSDKG_VerifyCommitment_400`.

  The database writes and the cold-read path are unchanged, so restarts, watchers and later quorum builds behave as before.

  ### Compared to #8130

  #8130 has the same idea but is +580 −9 across 7 files. This PR is +88 −6 across 3 files and reaches the same speed.

  One behaviour difference from #8130: under the legacy BLS scheme (before v19) a received vector is cached as decoded, without the subgroup check that the database read applies. #8130 falls back to the database read in that case. There's no reason to keep different behaviour for 2 scenarios.

  ## How Has This Been Tested?

  ### Measurements

  x86_64, blst, release build, 400 members / threshold 340:

  | Benchmark | Time |
  |---|---:|
  | `BLSDKG_BuildCommitment_cold_400` (decode from database encoding first) | 5.28 s |
  | `BLSDKG_BuildCommitment_cached_400` | 0.09 s |
  | `BLSDKG_VerifyCommitment_400` (per received commitment) | 0.018 s |

  Through the real `CDKGSessionManager`, using the end-to-end benchmark from #8130: 5.03 s on develop, 0.20 s with this PR, 0.22 s on #8130, same commitment hash in all three.

  ## Breaking Changes

  None. No protocol, message, consensus or on-disk change.

  ## Checklist:
  - [x] I have performed a self-review of my own code
  - [ ] I have made corresponding changes to the documentation
  - [x] I have assigned this pull request to a milestone _(if you have permission to set one)_

Top commit has no ACKs.

Tree-SHA512: fa65560612bbd1ac1d448a4e35cb1f3a4316257a5ff521f1cb503599c91a33ca221113d53f244b3db0d1ca1c4cf99de68f06118f6a6fcb25272f15b88b904136

…ugh the commit phase

898351d perf(llmq): keep verified DKG contributions cached for the session (Konstantin Akimov)
49d9ed5 bench: measure the DKG commit step at llmq_400_85 size (Konstantin Akimov)

Pull request description:

  ## Issue being fixed or feature implemented

  Building a premature commitment for `llmq_400_85` takes about 5 seconds of single-threaded work, almost all of it avoidable. `SendCommitment` and the verification of every received premature commitment call `CDKGSessionManager::GetVerifiedContributions`, which reads each member's verification vector back from LevelDB and decodes it: 400 members x 340 BLS public keys, about 34 µs per key (25 µs subgroup check, 8 µs point decompression). The contributions cache was filled only by reads and expired after 60 seconds, so it was always cold at commit time, although the DKG session still held the same vectors in memory.

  dashpay#8130 reports that this delay made members miss short commit phases on mainnet, and fixes it. This PR is a smaller alternative to the cache part of dashpay#8130.

  ## What was done?

  - `WriteVerifiedVvecContribution` now also puts the vector into `contributionsCache`, sharing the pointer the session already holds (no copy).
  - `WriteVerifiedSkContribution` updates the cached entry, so a share verified or justified later is visible to the next lookup.
  - `CleanupCache` drops an entry after 60 seconds only when nothing else references its vector, so entries live as long as their session and entries loaded from disk expire as before.
  - Benchmarks for the commit step at 400 members / threshold 340: `BLSDKG_BuildCommitment_cold_400`, `BLSDKG_BuildCommitment_cached_400`, `BLSDKG_VerifyCommitment_400`.

  The database writes and the cold-read path are unchanged, so restarts, watchers and later quorum builds behave as before.

  ### Compared to dashpay#8130

  dashpay#8130 has the same idea but is +580 −9 across 7 files. This PR is +88 −6 across 3 files and reaches the same speed.

  One behaviour difference from dashpay#8130: under the legacy BLS scheme (before v19) a received vector is cached as decoded, without the subgroup check that the database read applies. dashpay#8130 falls back to the database read in that case. There's no reason to keep different behaviour for 2 scenarios.

  ## How Has This Been Tested?

  ### Measurements

  x86_64, blst, release build, 400 members / threshold 340:

  | Benchmark | Time |
  |---|---:|
  | `BLSDKG_BuildCommitment_cold_400` (decode from database encoding first) | 5.28 s |
  | `BLSDKG_BuildCommitment_cached_400` | 0.09 s |
  | `BLSDKG_VerifyCommitment_400` (per received commitment) | 0.018 s |

  Through the real `CDKGSessionManager`, using the end-to-end benchmark from dashpay#8130: 5.03 s on develop, 0.20 s with this PR, 0.22 s on dashpay#8130, same commitment hash in all three.

  ## Breaking Changes

  None. No protocol, message, consensus or on-disk change.

  ## Checklist:
  - [x] I have performed a self-review of my own code
  - [ ] I have made corresponding changes to the documentation
  - [x] I have assigned this pull request to a milestone _(if you have permission to set one)_

Top commit has no ACKs.

Tree-SHA512: fa65560612bbd1ac1d448a4e35cb1f3a4316257a5ff521f1cb503599c91a33ca221113d53f244b3db0d1ca1c4cf99de68f06118f6a6fcb25272f15b88b904136
(cherry picked from commit 1abaa0d)

…ueued peer messages

0c3ba64 fix(llmq): process our own DKG messages ahead of queued peer messages (pasta)

Pull request description:

  ## Issue being fixed or feature implemented

  A masternode's own DKG messages (contribution, complaint, justification, premature commitment) are pushed onto the same pending queue as the messages it receives from peers, at the back. They are only verified and relayed when the DKG thread gets to them, so a node's own message waits behind every peer message that was already queued.

  In the commit phase that wait can be long. Each received premature commitment is verified one at a time on the DKG thread (a public-key-share computation and a pairing: about 20 ms on blst, several times that on relic), and in a 400-member quorum up to 399 of them can be ahead. A slow member that falls behind on verifying its peers' commitments therefore also holds back its own, and the commit phase is 4 blocks, which fast blocks have cut to under two minutes on mainnet (see dashpay#8135 for the rounds that failed). The other members can only count a commitment they have received.

  This PR used to carry a contribution cache change as well. dashpay#8135 does that part in less code, so it has been dropped from here; this is the remaining, independent change.

  ## What was done?

  `CDKGPendingMessages::PushPendingMessage` puts a message the node produced itself (`from == -1`) at the front of the queue instead of the back. Peer messages keep their order.

  Nothing else changes: the message is still verified by the same code before it is relayed, and there is no protocol, message, consensus or on-disk change.

  ## How Has This Been Tested?

  - New unit test `pending_messages_own_message_is_processed_first` in `llmq_dkg_tests`: with peer messages queued, a node's own message is popped first and the peer messages follow in their original order. It fails with the change reverted.
  - Unit tests `llmq_dkg_tests` pass.
  - Functional tests on this branch: `feature_llmq_dkgerrors.py`, `feature_llmq_simplepose.py` (both variants), `feature_llmq_rotation.py`, `feature_llmq_signing.py` (both variants), `feature_llmq_data_recovery.py`, `feature_llmq_connections.py` and `feature_llmq_chainlocks.py` pass.
  - The same commit on a `v24.0.x` build together with dashpay#8135's cache commit: unit tests `llmq*`, `dkg*`, `bls*`, `evo*` pass, and the functional tests above plus `feature_llmq_evo.py`, `feature_llmq_singlenode.py` and `feature_mnehf.py` pass.

  The effect on a mainnet-sized commit phase was not measured; the change is justified by the queue order alone.

  ## Breaking Changes

  None.

  ## Checklist:
  - [x] I have performed a self-review of my own code
  - [ ] I have made corresponding changes to the documentation
  - [x] I have assigned this pull request to a milestone _(if you have permission to set one)_

  🤖 Generated with [Claude Code](https://claude.com/claude-code)

ACKs for top commit:
  knst:
    utACK 0c3ba64

Tree-SHA512: c2078b24b75095470fc0549c4fa53396809a1cfb819c3fd25a38548ddded3cb03dcd609b380aa67ef11149422cf9a2d80ff1a6ea9e2d36061fa7e5a78a5455f8
(cherry picked from commit 1e3aeb3)

78ad074 Merge #8131: fix: wait for a matching superblock trigger before voting NO on the others (merge-script)
6faa5ce Merge #8097: fix: keep governance triggers across a restart on test networks (pasta)
2757e83 Merge #8130: fix: process a node's own DKG messages ahead of queued peer messages (merge-script)
cbbee0e Merge #8135: perf: keep verified DKG contributions cached through the commit phase (merge-script)
29a3cdd Merge #8099: fix(rest): don't terminate on blocks with undecodable ProTx payloads (merge-script)
275a142 Merge #8100: fix: don't abort in governance when a reorg changes masternode internal ids (merge-script)
d00c4e6 Merge #8104: fix: keep final commitments mineable when their block is rejected (merge-script)
b051d3a Merge #8080: test(qt): stop address book tests from answering the shared masternode wizard's prompt (merge-script)
ec9e944 Merge #8094: fix(net): stop busy-looping while a peer's send buffer is full (merge-script)
033dae3 Merge #8052: fix(qt): reserve the same shared masternode contribution again after a release (merge-script)
65603d5 Merge #8088: fix: fetch miniupnpc sources from miniupnp.free.fr (merge-script)

Pull request description:

  ## Issue being fixed or feature implemented

  Backports for v24.0.1, on top of `v24.0.x` at 938fba5 (v24.0.0). v24.0.0 is running on mainnet ahead of the V24 hard fork, and a handful of fixes that landed on develop since the release should not wait for 24.1: a `test_dash-qt` failure that blocks distribution packagers (#8075), a broken dependency download, a peer-triggerable busy loop, a way for a quorum commitment to be lost for a whole DKG cycle, and a node abort after a reorg.

  It also carries #8131, which changes when masternodes vote NO on superblock triggers. Inside a superblock's maturity window a masternode votes NO on every trigger that doesn't match its candidate and never revisits that vote. If the approved set changes while triggers are being created, masternodes can end up having voted NO on the trigger that matches their final candidate, and the superblock can go unpaid. With #8131 a masternode waits for a trigger matching its own candidate before it votes NO on the others (until 3 blocks before the superblock), and clears the per-cycle "voted YES" marker by height so an unfunded cycle doesn't carry over into the next one. This was a separate PR (#8132) until #8131 merged on develop; it is folded in here so the release branch gets one backport PR.

  It also carries the fixes for the `llmq_400_85` DKG rounds that have been failing on mainnet, which is what the stalled v24 activation is waiting on: #8135, which stops DKG members from reloading every verification vector at commit time, the reason slow members have been missing the commit phase of `llmq_400_85` rounds, and #8130, which makes a member relay its own DKG messages before it works through queued peer messages.

  ## What was done?

  ### Picked

  All eleven are picked from their develop merge commits with `git cherry-pick -m1 -x`. Each pick changes the same lines as its develop counterpart except where noted.

  - #8088 fix: fetch miniupnpc sources from miniupnp.free.fr
  - #8052 fix(qt): reserve the same shared masternode contribution again after a release
  - #8094 fix(net): stop busy-looping while a peer's send buffer is full
  - #8080 test(qt): stop address book tests from answering the shared masternode wizard's prompt (fixes #8075)
  - #8104 fix: keep final commitments mineable when their block is rejected, with the adaptation below
  - #8100 fix: don't abort in governance when a reorg changes masternode internal ids, with the adaptation below
  - #8099 fix(rest): don't terminate on blocks with undecodable ProTx payloads
  - #8135 perf: keep verified DKG contributions cached through the commit phase, with the adaptation below
  - #8130 fix: process a node's own DKG messages ahead of queued peer messages
  - #8097 fix: keep governance triggers across a restart on test networks, source change only (see below)
  - #8131 fix: wait for a matching superblock trigger before voting NO on the others

  ### Adaptations

  - **#8104:** `v24.0.x` doesn't have #7936 (parse each quorum commitment payload once per block). `src/llmq/blockprocessor.cpp` keeps the `v24.0.x` `GetCommitmentsFromBlock` and adds the new `RemoveMineableCommitmentsForBlock()` unchanged; in `blockprocessor.h` its lock annotation drops `!m_commitment_payload_mutex`, a mutex that only exists with #7936. `Chainstate` has no `m_special_tx` member on `v24.0.x`, so the two new calls in `validation.cpp` go through `m_chain_helper->special_tx`, like the neighbouring special-transaction calls. The `specialtxman.*` hunks are identical to the develop merge.
  - **#8135:** in `CDKGSessionManager::CleanupCache`, `v24.0.x` still has a hand-written erase loop that develop had already replaced with `std::erase_if`; the pick takes the new `std::erase_if` form. The benchmark added in `src/bench/bls_dkg.cpp` is left out: it conflicts with the `v24.0.x` version of that file and isn't needed on the release branch. The rest of the source change is identical.
  - **#8097:** only the source change is picked (two lines in `src/governance/governance.cpp`). It is needed for #8131's test: without it a masternode restarted inside the maturity window drops its stored triggers on regtest, testnet and devnets and then rejects the superblock, which is what the restart case of that test does. Mainnet is not affected by that bug, because the expiry check involved is skipped there. #8097's own `feature_governance.py` step is left out because it restarts the pruned node added with #7860, which `v24.0.x` doesn't have.
  - **#8131:** no conflicts; `src/governance/signing.cpp` on `v24.0.x` is identical to develop before the change.
  - **#8100:** the test fixture in `src/test/governance_vote_processing_tests.cpp` keeps `CBaseChainParams::REGTEST`, since `v24.0.x` predates `ChainType`. The source change is identical.

  ### Not picked

  - #8129 (re-sign a pending EHF signal on every block): an earlier revision of this PR carried it. It is still under discussion on develop, and v24.0.1 goes ahead without it: the EHF signal is attempted again when a newly formed quorum is selected for it, which the DKG fixes here are meant to make possible.
  - #8101 (reject InstantSend locks with a noncanonical version or cycle hash): an earlier revision of this PR carried it. It scores a peer 100 for relaying a lock with a non-current version, but nodes without the change accept and relay such a lock, so in a mixed network an upgraded node would discourage honest peers that are still on v24.0.0. It needs to stop scoring that case before it ships anywhere.
  - #8095 and its follow-up #8121 (block templates while the best ChainLock is above the tip): with both, a node refuses to build a template in that window, which is what v24.0.0 already does with a less helpful error. An earlier revision of this PR carried #8095 alone; it was dropped once #8121 merged.
  - #8102 (quorum scan cache): written on top of the #7956 refactor; it needs a hand-port to two functions on `v24.0.x`.
  - #8116 and #7815 (CoinJoin coordinator): long-standing, mixing only; #8116's test depends on #7815.
  - #8085, #8096, #8098, #8103, and the features, refactors, Bitcoin Core backports, CI and test-only changes merged since the branch point.

  ## How Has This Been Tested?

  macOS arm64, depends build with `--enable-debug --enable-werror`, no GUI. The current head is 78ad074.

  On the current head:

  - `dashd` and `test_dash` build cleanly.
  - Unit suites `governance*`, `llmq*`, `dkg*`, `evo*` and `versionbits*` pass, on the relic-based BLS library this branch uses.
  - `feature_governance_trigger_voting.py`, `feature_governance.py`, `feature_governance_cl.py`, `feature_governance_objects.py`, `feature_llmq_dkgerrors.py`, `feature_mnehf.py` and `interface_rest.py` pass.

  On earlier revisions of this branch. The current head has the same content as those revisions for the picks concerned; since then #8129 was dropped (one line in `src/llmq/ehf_signals.cpp` plus its test changes), the #8097 and #8131 picks were added, and the later picks were redone from their develop merge commits without changing the tree:

  - `feature_llmq_signing.py` (both variants), `feature_llmq_chainlocks.py` and `feature_llmq_rotation.py` pass (on the revision without #8097 and #8131).
  - Without the #8097 source change, `feature_governance_trigger_voting.py` fails in its restart case: the restarted masternode rejects the superblock with `bad-cb-amount`.
  - Unit suites `bls*` pass. On a revision that also carried #8095 and #8101, `coinjoin*`, `net_tests`, `miner_tests` and `validation*` passed as well.
  - The full functional suite (`test_runner.py -j16`), on the revision that still carried #8129 and not yet #8097 and #8131: 307 passed, 17 skipped, 1 failed. The skipped ones are the usual environment-dependent tests (`*_bind*`, `interface_usdt_*`, `interface_zmq*`, previous-release compatibility and `feature_unsupported_utxo_db.py`). The run includes `feature_llmq_dkgerrors.py` with #8104's new scenario and `interface_rest.py` with #8099's.
  - The failure was `feature_llmq_signing.py`, in its first `mine_quorum`, waiting for every member to have received all contributions. The node logs show one masternode relaying its contribution about 0.2 s before its connections to the other members had been authenticated, so no peer received it. That happens before anything #8135 or #8130 changes, and it is load-dependent: running four copies of the test in both variants at `-j8`, three times, 2 of 24 runs fail on that revision and 2 of 24 fail on the same branch without the two DKG commits, with the same assertion.
  - A full functional run with the #8097 and #8131 changes on top of an older revision of this branch: 310 passed, 17 skipped, none failed.

  #8131 describes its scenarios and how each was shown to fail without the change.

  The GUI picks (#8052, #8080) were not built or run locally; CI covers them. The first push of this branch did not compile (`m_special_tx`, see Adaptations); review caught it and it was fixed before any of the above was run.

  ## Breaking Changes

  None. Behaviour change for masternodes (#8131): a NO vote on a non-matching trigger may be cast later than before, when the masternode's own candidate has no trigger yet, and at the latest 3 blocks before the superblock.

  ## Checklist:
  - [x] I have performed a self-review of my own code
  - [ ] I have made corresponding changes to the documentation
  - [x] I have assigned this pull request to a milestone _(if you have permission to set one)_

  🤖 Generated with [Claude Code](https://claude.com/claude-code)

Top commit has no ACKs.

Tree-SHA512: 8ce635d02dd2b9b285aa6a1630d329ffeb9dcb99947a7a758c80ed17a2dbeb7496162a7f3052e872f46d481c6e6391ce866fd296d3ef1fa8edb1dc2d2c5f275e

038306f chore: prepare v24.0.1 release (pasta)

Pull request description:

  ## Issue being fixed or feature implemented

  Prepares the **v24.0.1** point release on top of the v24.0.1 backports (#8128), following the v23.1.10 prep (#7983). v24.0.1 carries the fix for what has held up `v24` activation on mainnet (`LLMQ_400_85` DKG rounds failing at the commit step, so no new quorum is selected to sign the EHF signal), plus a small set of other fixes.

  ## What was done?

  - `configure.ac`: `_CLIENT_VERSION_BUILD` 0 → 1 (`_CLIENT_VERSION_IS_RELEASE` stays `true`, no RC).
  - `doc/release-notes.md`: v24.0.1 notes covering #8135, #8130 and #8104 (v24 activation), #8131 and #8097 (governance), #8100, #8094, #8099 and #8052 (other fixes), and #8088 and #8080 (build and tests). Upgrade and downgrade notes point to the v24.0.0 notes for everything that applies when coming from v23.
  - Archived the v24.0.0 notes to `doc/release-notes/dash/release-notes-24.0.0.md` (verbatim copy), added v24.0.0 to "Older releases", and pointed the change log link at `v24.0.0...v24.0.1`.
  - `contrib/flatpak/org.dash.dash-core.metainfo.xml`: `24.0.1` release entry dated 2026-11-12. The date needs changing if the tag is cut on another day.
  - `doc/man/*.1`: version string bump only; no CLI option changed since v24.0.0.

  ## How Has This Been Tested?

  Release mechanics only; no code changes.

  - Built the branch (macOS arm64, wallet, no GUI); `dashd -version` and `dash-cli -version` report `v24.0.1`.
  - Regenerated the `dash-cli`, `dash-tx`, `dash-wallet` and `dash-util` man pages with `contrib/devtools/gen-manpages.py` from that build: byte-identical to this commit. `dashd.1` differs from the regenerated one in a single line, the `lock` debug category that only an `--enable-debug` build lists, so the committed page matches a release build. `dash-qt.1` got the same version-only bump and wasn't regenerated (no GUI build).
  - The archived 24.0.0 notes are byte-identical to the previous `doc/release-notes.md`.
  - The notes were checked against the merged diffs and kept to effects.

  ## Breaking Changes

  None in this PR. The behaviour changes that ship in the fixes are described in the notes: masternodes cast some NO-FUNDING trigger votes later than before.

  ## Checklist:
  - [x] I have performed a self-review of my own code
  - [x] I have made corresponding changes to the documentation
  - [x] I have assigned this pull request to a milestone _(if you have permission to set one)_

  🤖 Generated with [Claude Code](https://claude.com/claude-code)

Top commit has no ACKs.

Tree-SHA512: 1553e82ef0da95830bf0edada0354820da75d72645faec37663694dc790f816fe597f220abee7bad0485be4d41596d26d27f0d2bfc44a05510d71346f5a3204c